From Oak:

10:

The Option<Vec<...>> type is prevalent across the codebase. Although it can distinguish between an empty and an absent list in certain scenarios, its usage is generally discouraged.

For example, in packages/dao-voting/src/pre_propose.rs:72-84, the PreProposeSubmissionPolicy enum declares the denylist and allowlist fields to Option<Vec>. The lists are parsed with unwrap_or_default, which converts empty lists to None before updating the submission policy configuration in packages/dao-pre-propose-base/src/execute.rs:291 and 365. This indicates there is no meaningful distinction between None and an empty vector.

Hence, we conclude that Option<Vec<...>> serves more as an optimization than a necessity. Given that modern Rust minimizes the memory footprint of empty vectors, the complexity added by Option<Vec<...>> pattern outweighs its benefits.

Consequently, the code complexity is increased due to additional checks and unwrapping without a significant memory efficiency gain.

12:

The code segments in packages/dao-pre-propose-base/src/execute.rs:262-283, 307-328, and 330-351 are identical. These segments implement modifying permission lists with iteration, deduplication, and address validation, which can be abstracted as reusable components to reduce the attack surface and increase code maintainability.

This fix replaces all Option<Vec<String>> instances with Vec<Addr>, except those in the update submission policy message, since that allows the caller to omit fields from the JSON entirely, which is a desirable optimization for frontends.

It also de-dupes some redundant code.